前言

OpsWorks 被 AWS 宣告要 EOL，跟據筆者主管非常精闢的描述，就是「動搖國本」。因為敝公司幾個最大最古老的專案，也就是採用 EC2 解決方案的那些專案，全部都使用 OpsWorks 進行 Configuration as Code 的工作。

另一方面，跟據 AWS 文件：AWS OpsWorks for Chef Automate End of Life FAQs - AWS OpsWorks (amazon.com) 中的描述，目前仍然在使用該服務的使用者，最快只到明年(2024年)5月就要完成全部的搬遷。從接收到訊息開始，大概只剩下一年多一點點的時間，因此可以說是非常趕。

由於這個搬遷仍然處在前期的進行階段，因此還沒有比較多的內容可以分享給讀者，但這裡還是先用一篇文章的方式，來分享目前遇到的各種疑難雜症。

主文

EOL 的端倪

其實我們也一直都看得出來 OpsWorks 看起來像是一個隨時要被 AWS 捨棄的專案。比如說，該服務的 console 頁面屬於比較古老的形式，如同Classic Load Balancer 的頁面一樣。可以參考下圖：

所謂古老的形式，以上圖為例，除了沒有支援 dark mode 之外，裡面的各類 button 的設計也和現在比較新介面的 button 不同。可以參考下圖來與比較新的界面比較：

除了介面之外，筆者最有感的就是在準備 AWS 相關證照的時候，幾乎沒有出現過任何與 OpsWorks 有關的題目。唯一一次在 Solution Architect Professional (SAP) 的考古題中，也只是非常單純地考到 OpsWorks 的底層是由 Chef 和 Puppet 寫成的而已。

最後則還有一件事情，在某次 P0 事件中，筆者很緊急地與 AWS 工程師通訊來排查問題。當時出現的狀況與 OpsWorks 有關，但負責處理的工程師看起來對這個服務也是一知半解。這當然與當時因為太過緊急而導致臨時調派的人力其實並非團隊成員有關，但也可以看得出來，在維護該服務上的人力可能也在逐漸減少。事實上，在某次與 AWS 閒聊到這件事的時候，也才得知目前 OpsWorks 的負責團隊主力已經被移轉到 SSM 上了。

替代方案的選擇

雖然流水線的佈置在敝公司其實並非 SRE 的主要工作，但在訊息派發之後並進行初步的研究後，筆者得到以下幾個解決方案，提出來與團隊進行後續的討論：

System Manager

可以參考官方文件，是 AWS 官方比較建議的做法。

但在經過公司前輩的討論後，因為需要在System Manager裡面建置過多複雜的指令的關係，決定先放棄這個選項。

Golden AMI + User Data

在之前日常維運系列文章中，有提過 OpsWorks 註冊失敗的問題，而其中一個由另一位資深工程師在主導研究的解決方案，就是透過 Golden Image 的方式來避免開機後才進行套件安裝，從而增加安裝失敗的可能性。

大部分資深工程師都認為，這個方法相較前者會比較適合公司目前的做法。首先，如果把作業系統(比如 Ubuntu)在一開始就放在 Golden AMI 裡面，那可以直接解決有時候 Ubuntu Server 壞掉，導致 EC2 開失敗的狀況；此外，大部分的驗證可以在 Build 階段完成，不需要等到部署再找問題；也因為大部分的東西都先 Build 好了，可以大幅加快部署速度。

ECS Fargate

這是一個比較複雜的解決方案，但無伺服器的解決方案可以減少未來管理伺服器的麻煩，因此就長遠來說會是最適合的方案。事實上，我們在之前維運 EC2 上已經吃過非常多苦頭，也越來越可以感受到容器化對於避免 operation overhead 的重要性。

然而，除了搬遷本身可能需要更多人力的研究之外，最困難的地方可能就是要如何說服開發工程師了吧。因為一般容器的映像檔會需要在 repo 裡放 Dockerfile 以及一些新的驗證機制。這對於沒有碰過容器的工程師而言會是一種挑戰，如何說服他們這在維運上可以減輕的負荷，也會需要一些溝通的藝術才行。

最後的選擇

事實上，雖然與開發工程師的主管有過許多的討論，但最後我們仍然決定直接採用容器化的解決方案，也就是比較一勞永逸的方式了。在這整個討論過程中，甚至還有遇到一些資深的開發工程師直接跳出來協助寫 Dockerfile，筆者也是打從心理深深感到佩服。

不過，讀者可能會想詢問，同樣是容器化，為什麼我們不選擇 EKS 的解決方案呢？事實上，筆者一開始也非常困惑，並從主管那裡得到，這主要還是與後續的維護難度有關。Kubernetes 是一個迭代非常快速的產品，因此在進行該服務版本的升級時常常會佔用大量的時間，這也是我們其中一個專案目前在維運上的痛點之一。相較於此，由於我們一來沒有地端或與其它雲端混用的狀況，而且我們的網路設定也沒有複雜到會需要 Kubernetes 的協助，因此使用 AWS 主要負責維護的 ECS Fargate，就會是容器化後的優先選擇。

時程、人力、資源調配

與其他的服務維護事件相同，在產品經理得到該訊息後，就要開始盤點人力與分配可用資源，再透過前面提到的結果來安程後續的時程。這裡最主要的任務，應該一來是要將原本的程式轉為容器化的寫法，另一個則主要會是要建置 ECS Fargate 的 infrastructure 和 deployment pipeline。SRE 的出場則會在比較後期，主要任務會如下：

• 建置新的監控系統
• 分析壓力測試的結果來推測自動擴展的合理設定
• 維護模式工具的重新設定
• 報表工具的調整
• 維護文件的更新

可以看得出來，以上工作幾乎都至少要在整個新架構上線之後才能開始測試，因此就目前而言，筆者還沒有太多可以分享的細節。但從這些預期的工作內容中，讀者應該也可以看出 SRE 主要負責的工作內容的角度與取向。

實際上，筆者負責的專案因為有非常厲害的開發工程師可以協助處理 Dockerfile，再加上需要修改的 API 數量較少，因此工作量相較於其它專案就幸運地少上許多。其它專案中就有出現需要由 SRE 協助寫 Dockerfile 的狀況，我們團隊也為此額外開設了每週一起研讀容器化技術的讀書會呢。

後記

OpsWorks EOL 的事件一則以喜，一則以懼。懼的是在於搬遷工作非常複雜，而在時間有限的情況下，到底能否順利搬遷完就會是一個未知數；喜的則是，從很多維運前輩的話語都可以聽得出來，他們終於找到一個適合的理由來脫離 OpsWorks 了。從過去的各種部署或維運事件中，也可以看得出來有很多人維護得很辛苦，但在沒有重大理由的情況下，要貿然進行搬遷事宜則難以讓公司高層接受。透過這次機會終於也可以順便對舊有的系統進行架構上的重構，也是一件讓人相當開心的事情。

對於彼此而言，想法其實也和其他人沒有差上非常多。因為本身也正在忙其他工作的關係，其實一定程度上，也對資澦與人力是否足夠感到相當焦慮； 但另一方面，能夠透過這個時間來一勞永逸地解決後續維運上的困擾，還能夠在過程中同時精進自己容器化的技術，這會是筆者覺得最開心也最興奮的事情。

雖然很可惜，沒有辦法在這次的鐵人賽從完整分享接下來會遇到的細節，但也希望讀者能夠從目前的內容中，理解在類似這種重大的搬遷事件裡，SRE 可能會扮演什麼的角色。

而寫到這裡，鐵人賽的主文也算是告了一個段落了。不知道讀者對於 SRE 有沒有什麼新的想法呢？ 如果對這個職位有興趣的話，下一篇的主題會是，往 SRE 這條路前進時可以努力的方向，以及一些在心態上的心得分享。